Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implement more methods on stable Rust #27

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

GnomedDev
Copy link

Replaces most of the usage of generic_const_exprs with typenum based math.

Pros:

  • More methods usable on stable

Cons:

  • Higher complexity, as typenum math requires a ton of bounds
  • Only supports iterators up to 1024 length, as written in helpers.rs as the typenum_mapping call.

This method of using typenum to replace GCE was originally developed for https://github.com/GnomedDev/aformat, and seems to work well from the user perspective.

Sadly, I wasn't able to replace flat_map, as one limitation is how I cannot use "return type impl trait" (RTIT) as the type must be named in the where bounds and this is necessary whenever closures are involved as they are totally unnameable.

@usbalbin
Copy link
Owner

usbalbin commented Jul 23, 2024

I am not quite sure if this is worth it. As you say there is quite a complexity trade of, going from zero to two dependencies, more complex bounds etc...

@gwen-lg
Copy link
Contributor

gwen-lg commented Jul 23, 2024

I'm agreed with @usbalbin, I think is an different approach which does not correspond to the philosophy of crate iter_fixed.
If there is enough interest, you can create an other crate with this approach, and ask to add a link in readme. Or possibly an acceptable compromise would be to use this only on feature not enabled by default.

@GnomedDev
Copy link
Author

What is said philosophy? Would you be okay if I locked this behind a feature like the nightly usage?

@usbalbin
Copy link
Owner

usbalbin commented Aug 4, 2024

@gwen-lg do you have any thoughts? Personally making it optional behind a feature flag feels a lot better. Still keeping it quite simple and with zero deps for those who dont want any, yet enabling nice features for those that need them.

When the day comes and the required lang features are stabelized the extra complexity can be removed as well as the feature gate.

@gwen-lg
Copy link
Contributor

gwen-lg commented Aug 4, 2024

I'm ok if it's behind a feature flag disabled by default ;)

@GnomedDev : my vision of philosophy of the crate is : simple, no dependency, no unsafe.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants